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(54) Title: A MARKET OPERATING SYSTEM 
(57) Abstract 

A market operating system for confirming the details 
of trades already agreed between a buyer and a seller. The 
system comprises an electronic controller (12) that is adapted 
to communicate via a communication network (11) with a seller 
terminal (10) and a buyer terminal (10). Included in the electronic 
controller ( 1 1 ) is a register of market members (3 1 ) and a memory 
that includes a plurality of contract terms, the contract terms 
being selectively retrievable by a market member from the seller 
terminal (10). When confirmation is required, terms selected by 
the seller are imported into an agreement that is to represent 
the agreed trade. The agreement is then stored and a message 
is forwarded to the buyer terminal (10) as notification of the 
presence of the agreement The buyer is then allowed access to 
the agreement entered by the seller. Once the buyer has reviewed 
the terms, the agreement can either be accepted or rejected. 
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A MARKET OPFR A TING SYSTEM 

The present invention relates to a market operating system. 

Markets exist in many forms. The participants consist of end users and 
intermediaries. The end users are for example producers and consumers, or, 
capital providers and investors, and the intermediaries are, for example, traders, 
brokers, clearers, fund managers and advisers. Markets may be domestic or 
global in nature and may be organised markets such as exchanges, operating 
with or without centralised clearing. Alternatively, the market may be a loose 
network of individuals or firms trading by telephone or otherwise. 

In order to function, markets require a method of trading that includes deal 
confirmation and settlement or performance of the contracts entered into by the 
market participants. In some organised markets, these methods are codified 
within the rules and procedures of the various exchanges and clearing houses. 
Other organised markets, for example foreign exchange markets, operate 
through service providers such as Reuters. 

In organised exchange markets there are essentially three relationships - 
multilateral member/member; bilateral member/customer and bilateral • 
customer/customer. A multilateral member/member relationship is one in 
which a member of the market has a relationship with a plurality of other 
market members. A bilateral member/customer relationship is one in which a 
member of the market has a relationship with a non-member of the market. A 
bilateral customer/customer relationship is one in which the parties are not part 
of the market 
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In most cases the member/member trading relationship is either on a trading 
floor or a real time electronic system, both of which are expensive. There is, 
therefore, a need for a market operating system that allows market participents, 
whether or not members of an exchange, to confirm relatively quickly and 
cheaply the details of trades. 

According to one aspect of the present invention there is provided a market 
operating system for confirming the details of trades already agreed between a 
buyer and a seller, the system comprising an electronic controller adapted to 
communicate via a communication network with a seller terminal and a buyer 
terminal, the electronic controller comprising means adapted for registering 
market members, a memory that includes a plurality of contract terms, the 
contract terms being selectively retrievable by a market member from the seller 
terminal, means for importing a selected term into an agreement that is to 
represent the agreed trade, means for storing the agreement completed by the 
seller, means for sending a signal to the buyer terminal to notify the buyer of the 
presence of the agreement, means for allowing the buyer to view the agreement 
entered by the seller and means for receiving a response from the buyer 
terminal to indicate whether or not the agreement is accepted or rejected. 

When the buyer views the agreement, preferably the controller is adapted to 
provide a prompt requesting the buyer to indicate either acceptance or rejection 
of the agreement. When the buyer enters a response, this is forwarded to the 
controller from the buyer terminal. 
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Preferably, details of the agreement are automatically stored in a central 
database and an indication is provided in the database as to whether or not the 
agreement is accepted or rejected. If the agreement is accepted, the database is 
up-dated to show this. If the agreement is rejected, the database is likewise up- 
dated. 



Preferably, the system further comprises means for selecting a customised list 
of the contract terms for presentation to a particular market member at the seller 
terminal, the contract terms in the customised list being each selectively 
retrievable by the particular market member from the seller terminal. The 
customised list may include the details of counter parties with whom the market 
member is authorised to trade. The customised list may include the details of 
brokers with whom the market member is allowed to trade. Preferably, a 
plurality of customised lists is provided. 

Preferably, each member is allocated a unique member number. Preferably, the 
contract terms that are usable by a particular member are stored together with 
the unique member number. Preferably, the controller is adapted to search the 
stored contract terms to select those terms that arc stored together with a 
particular unique member number and use the results of the search to compile 
the customised list of contract terms. The agreements entered by the seller are 
preferably stored together with the unique member number. 



Preferably, each market member may designate users to operate on its behalf 
the market operating system. For example, the market member may be a 
company and the designated users may be authorised employees. Preferably, 
each user is allocated a unique user identification (ID) number. Additionally, 
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the user may have a password, for added security. Agreements entered by the 
seller are preferably stored with the unique member number and the unique user 
ID. 



Preferably, in order to access the market operating system, the user has to enter 
his unique member number and, where appropriate, unique user ID. Preferably 
the controller is adapted on entry of the unique member number and, where 
appropriate, unique user ID, to search the database of agreements, select all 
those that include reference to the unique member and, where appropriate, user 
ED number entered by the user and present to the user a customised listing of all 
the agreements found. Preferably, the customised listing of all the agreements 
includes an indication as to the status of the trade, i.e. whether the agreement 
has been confirmed, i.e. accepted, or rejected. 



15 Preferably, the controller is adapted to receive information from the seller 
terminal relating to the nature and price of the goods for sale in the market, 
which information is imported into the agreement 

Preferably, the controller is adapted to receive a signal from the buyer terminal 
20 indicative of whether or not the agreement is accepted or rejected as 
representing the trade previously agreed. 

Preferably, an encoder is provided for encrypting the details of the agreement so 
that the offer is readable only by the selected buyer. 



25 



Preferably the controller is adapted to present at the seller terminal a template of 
the trade agreed between the seller and buyer, the details of which are to be 
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completed by the seller. Preferably, the template includes a menu that can be 
opened, thereby to allow the seller to select contract terms for incorporation into 
the agreement. Where customised lists are provided, preferably the menu is a 
listing of the customised list. 

According to another aspect of the present invention there is provided a method 
for confirming the details of trades already agreed between a buyer and a seller, 
the method comprising: 

registering market members; 

storing a plurality of contract terms, the contract terms being selectively 
retrievable by a market member from the seller terminal; 

importing a selected contract term into an agreement that is to represent 
the agreed trade; 

storing the agreement completed by the seller; 

sending a signal to the buyer terminal to notify the buyer of the presence 
of the agreement, 

allowing the buyer to view the agreement entered by the seller, and 
receiving a response from the buyer terminal to indicate whether or not 
the agreement is accepted or rejected. 

According to another aspect of the invention, there is provided a computer 
program for controlling communication between a seller terminal and a buyer 
terminal, the computer program comprising means for registering market 
members, means for presenting to a market member at the seller terminal a 
plurality of contract terms that is stored in memory, means adapted to enable 
selection of a desired contract term from the list using the seller terminal, means 
for including the selected term in an agreement, means for storing the 
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agreement completed by the seller, means for sending a signal to the buyer 
terminal to notify the buyer of the presence of the agreement and means for 
receiving a response from the buyer terminal to indicate whether or not the 
agreement is accepted or rejected. 

According to yet another aspect of the invention, there is provided a data 
storage means containing a computer program for controlling communication 
between a seller terminal and a buyer terminal, the program comprising means 
for registering market members, means for presenting to market members at the 
seller terminal a list of contract terms that is stored in memory, means adapted 
to enable selection of a desired contract term from the list using the seller 
terminal, means for including the selected term in an agreement, means for 
storing the agreement completed by the seller, means for sending a signal to the 
buyer terminal to notify the buyer of the presence of the agreement and means 
for recezving a response from the buyer terminal to indicate whether or not the 
agreement is accepted or rejected. 

Preferably, the computer program further comprises means for selecting a 
customised list of the contract terms for presentation to a particular market 
member at the seller terminal, the contract terms in the customised list being 
each selectively retrievable from the customised list by the particular market 
member from the seller terminal. 

THe customised list may include the details of counter parties with whom the 
market member is authorised to trade. The customised list may include the 
details of brokers with whom the market member is allowed to associate. 
Preferably, a plurality of customised lists is provided. 
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Preferably, each member is allocated a unique member number. Preferably, the 
contract terms that are usable by a particular member are stored together with 
the unique member number. Preferably, the unique member number is entered 
by the market member. Preferably, the computer program is adapted to search 
the stored contract terms to select those terms that are stored together with a 
particular unique member number and use the results of the search to compile 
the customised list of contract terms. 

Preferably, the computer program is adapted to present to a seller a template of 
an agreement into which the seller enters details of the trade that is to be 
confirmed. Preferably, the template has a plurality of data entry fields. Where 
a customised list is provided, preferably, data can be entered into at least one of 
the data entry fields by selection from that list. 

A method of establishing an electronic market operating system for confirmaing 
details of pre-agreed trades, the method comprising 
registering a plurality of market members; 

providing lists of available products that are selectable by market users; 
providing a plurality of contract terms, and 

marking the contract terms so that they are selectable for incorporation 
into a customised list of contract terms for presentation to a particular market 
member at a seller terminal. 

Preferably, the method further comprises presenting the contract terms in the 
customised list to the particular market member at the seller terminal, providing 
means to allow selection by the particular market member of contract terms 



WO 00/70484 



PCT/GB00/01879 



from the customised list and electronically importing the selected terms into a 
pre-detennined user agreement. 

According to yet another aspect of the present invention there is provided a 
method of gathering market information comprising 

establishing an electronic market operating system for confirming details 
of pre-agreed trades; 

registering market members, and 

storing anonymously pricing details of all trades confirmed using the 
market operating system. 

A market operating system in which the invention is embodied will now be 
described by way of example only with reference to the following Figures, of 



which: 



Figure 1 shows a diagrammatic representation of the market operating 
system; 

Figure 2 is a representation of the system web page, 

Figure 3 is a table that shows the various interactions that take place 

during use of the system, and 

Figure 4 is a template of an agreement that is presented to a seller. 



via a 
a server 



Figure 1 shows a plurality of user PCs or work stations 10 connected 
telecommunications network 1 1, for example the World Wide Web, to 
12 on which is installed a generic market operating system. The market 
operating system includes software that enables a member of the market to 
confirm in a manner that is legally binding a pre-agreed sale of goods. As 
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standard, an offer for sale is subject to certain contractual restrictions that are 
specified by the seller and negotiated with the buyer. These negotiations are 
typically carried out by telephone. Once the terms of the sale are settled, the 
seller uses the market operating system to select some of the agreed terms from 
a menu of pre-determined available contract terms and enters other terms, such 
as the price, manually. When the desired terms are selected these are imported 
into a User Agreement A message is then sent to notify the buyer of the 
presence of the agreement as defined by the seller. 

When a buyer receives the message, the details of the agreement can be checked 
to see if they concur with what was agreed verbally. The buyer can then either 
accept or reject the agreement as the case may be. If an agreement is rejected 
the seller is notified of this via e-mail. The seller then has the option to alter 
and thereby make any corrections to the terms of the trade. A message 
including the revised details of the agreement is then forwarded to the buyer. 
This process continues until the agreement is finally accepted or rejected. If an 
agreement is accepted the seller is notified via e-mail and a record of the 
transaction is saved. 

Typically, the market operating system is accessible via a dedicated web site, 
although it could be implemented on any other suitable data communications 
network, for example a wide area network or a local area network. The system 
server should preferably be a database driven web-server and the site should 
preferably have the majority of the system rules embedded in standard query 
language statements that can be used to interact with databases stored at the site. 
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An example of the first page of a suitable site is shown in Figure 2. This 
provides links 20 to all the main site sections, including a public site that 
provides information on the system, together with legal information, and links 
to related sites. In addition, a "login" link 2 1 is provided to private market 
member sites. Also available are links to explanations of the various "clear 
sites" that are present Each of these sites provides access to particular trading 
options. For example the site marked "Oilclear" 22 is dedicated to trades 
relating to oil and that marked "Metalclear" 23 is dedicated to trades relating to 



metal. 



as a 
a 



In order to use the market operating system, each user firstly has to register 
market member. To this end, the first page of the web site is provided with 
registration link 24 to a registration page. Once the registration page is 
accessed, the user is asked to provide the system server with personal details 
such as name, address, contact name, telephone number, fax number and e-mail 
In addition, the member has to agree to the terms set out in a market operating 
system User Agreement that defines both the contract terms and a large part of 
the overall terms of business. 

Once registered, each member is allocated a unique member number that is 

stored in a member_no field in a MEMBER table 3 1, as shown in Figure 3. 

Stored in association with the member_no field are the following fields: 
Meraber address - this contains the member's address, 
Member_name - this contains the member's name, which is typically a 

company name 

Member_contact - this contains details of the member's contact, 
typically an employee within the member company 
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Membertel - this contains the member's telephone number, 
Memberjax - this contains the member's fax number 
Member_e-mail - this contains the member's e-mail number, and 
Member.default - this contains the member's default code which sets which 
clearing system is automatically presented to a member on entry into the 
system, for example some members may wish to automatically enter the 
Oilclear site whilst others may prefer to enter the Metalclear site. 

The member_no field is linked to all the other "member" fields, so that by 
selecting a particular unique member number from the MEMBER table 3 1 for 
example by double clicking on the member number, access can be gained to all 
of the associated data on that member, as shown in Figure 3. Access at this level 
is, however, generally only permitted for system administrators. 

Typically market members are companies. Therefore, in order to identify 
traders within member companies, each individual user is additionally provided 
with a unique user identification (ID) number. The user ID is stored in a 
user.id field in a USER© table 32 (see Figure 3) that lists the IDs of all users 
registered in the market, together with the member number of the parent 
company. Stored in «user_id-» fields in association with the user ID are a user 
password and information relating to the authorised user security level, which 
can be varied according to the needs of the members. Additionally stored in 
"user_id_" fields are the user's name, telephone number, facsimile number and 
e-mail number. The user_id field is linked to all the other "user_id_" fields, so 
that by selecting a particular user ID from the USERID table 32, for example by 
double clicking on the user ID number, access can be gained to all the 
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associated data on that user. As before, access at this level is, however, 
generally only permitted for system administrators. 

In certain circumstances, users can be registered in a specific grouping. For 
example, as shown in Figure 3, brokers can be registered as such. To this end a 
broker when registering will supply his name, address, contact number and 
other details as before. Once this is done the broker is assigned a unique 
member number and a broker code, each of which is inserted into a broker_code 
field in a BROKER table 33. Linked to the broker_code field are "broker." 
fields that contain the broker's details, such as name, a mnemonic or three letter 
abbreviation representing the broker's company name, address, contact details, 
telephone number, fax number, and e-mail number. Of course, each broker that 
is registered also has an associated unique member number that is also stored in 
a field in the BROKER table 33. Since the broker_number field is linked to all 
the other "broker." fields, by selecting a particular broker number from the 
BROKER table 33, for example by double clicking on the broker number, 
access can be gained to ail the associated data on that broker. Access at this 
level is, however, generally only permitted for system administrators. 

Brokers are typically not actively involved in the confirmation process but a 
record is kept of trades that are arranged by particular brokers. 

In order to facilitate the entry of product details into the system, a product 
(PROD) table 34 is provided as shown in Figure 3. The PROD table 34 contains 
prod_code fields that include product codes for the various products that can be 
traded. Each prod_code field in the PROD table is linked to further "prod_" 
fields that contain details such as a description of the product the type of 
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25 



product, the product category, ie is it a bullion market product or an LME 
product, the order in which the products are to be presented to members and the 
product date and format ie the date and how this is presented. Since the 
prod.code field is linked to all the other «prod_» fields, by selecting a particular 
product code from the BROKER table 33, for example by double clicking on it, 
access can be gained to all the associated data on that product As before, 
access at this level is, however, generally only permitted for system 
administrators and not for traders in the front office. 



Traders typically will only do business with specific parties with whom they are 
acquainted. It is taken, therefore, as a basic premise that the system users will 
each have a customised list of specified counter-parties with whom they will 
deal bilaterally and register the resulting trades. Most firms will for sound 
commercial reasons operate rigorous credit and "due diligence" checks before 
opening an account with or for another firm. However, there may be legal (e.g. 
money laundering statutes) and regulatory (e.g. FSA Rules) imperatives 
requiring such precautions. This list of approved counter-parties is one of the 
variable terms in any trade that the user may wish to confirm. This may vary 
not only in relation to each of the markets but also to the specific contracts 
20 within it. Each market member or even each market user within a specified 
member company will have different counter parties with whom they will do 
business. 



The details of the counter parties or buyers to whom at least one market 
member is prepared to sell, together with details of credit limits and other 
relevant information, are stored in a counter party (CPARTY) table 35. 
Confirmation of trading details can only be effected between members of the 
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market and so every counter party must have a unique member number. This 
member number is stored in the member_no field of the CPARTY table 35. If a 
market member wishes to establish a relationship on the market operating 
system with a specified counter party then that counter party is allocated a cpart 
code that is entered into a cpart_code field in the CPARTY table 35. Linked to 
the cpartcode field is a cpartmember field, which contains the member 
number of the member who wishes to trade with that particular counter party. 
Additionally linked to the cpart_code field are further "cpart_" fields that 
contain the counter party's details, such as name, a three letter mnemonic 
representing the counter-party name, address, contact details, telephone number, 
fax number, e-mail number and the credit limit agreed with seller. 

In addition, the CPARTY table 35 may include an e-maiUnitial field. If this is 
included, then when an agreement is entered into the system by a seller, an e- 
mail indicating the presence of the agreement is forwarded to the selected 
counter party. The CPARTY table 35 may also include an e-mail_confirm 
field. If this is present, then when an agreement is confirmed by the counter 
party or buyer an email indicating confirmation of the agreement is forwarded 
to the e-mail address in the e-mail_confirm field, which is typically the seller e- 
mail number. 



Since the cpart.code field is linked to all the other "cpart J' fields, by selecting 
a particular cpart code from the CPARTY table 33, for example by double 
clicking on it, access can be gained to all the associated data on that counter 
party. As before, access at this level is, however, generally only permitted for 
system administrators and not for traders in the front office. 
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In order to facilitate the entry of specific clauses into the agreement, a terms 
(TERMS) table 36 is provided as shown in Figure 3. The TERMS table 36 
contains a listing of terms codes associated with the various clauses that can be 
selected. Each terms.code in the TERMS table 36 is linked to further details 
such as a description of the term and its full text. 



are 



The MEMBER, USERID, BROKER, PROD, C PARTY and TERMS tables 
sources of largely static information and each is linked to a market transaction 
table 37, marked TRAN in Figure 3. This is the main dynamic table that stores 
details of all the transactions that are entered into the system by traders. Each 
transaction that is entered onto the system is allocated a unique transaction 
number that is put into a trannumber field in the TRAN table 37. The 
tran_number field acts as a link to fields that contain further details of the trade. 
As is shown in Figure 3, the TRAN table 37 contains the following further 



fields: 



Member_no - this stores the unique member number of the user 
forwarding the message 

Trancode - this stores a transaction code that indicates the category that 
the transaction belongs to, 

Tran_prod_desc - this stores a description of the product that is being 
traded 

Tran_volume - this stores the quantity of that product 
Tran_start_month - this is used for storing the start date of a spread and 
is the month which the member sells 

Tran_end_month - this stores the last date of a spread and indicates the 
month in which the member buys 
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Tran_day - this stores the day on which the trade is available 
Tran_price - this stores the price of the trade 

Tran_user_id - this stores the unique user ID of the member making the 
offer 

5 Tran_cpart_nmem - this stores the mnemonic or three digit abbreviation 

of the counter party name 

Tran_broker_code - this stores the broker code, if appropriate 

Tran terms code - this stores the terms code that indicates the terms 

selected by the user 
10 Tran_price_ref - this stores the price reference 

Tran_addendum - this stores text that is added by the seller 

Tran_date - this stores the date of the transaction 

Tran time - this stores the time of the transaction 

Tran_date_confirm - this stores the date on which the transaction is 
15 confirmed as acceptable 

Tran_time_coiifirm - this stores the time at which the transaction is 
confirmed as acceptable 

Tran_reject_rems - this stores a flag to indicate that the trade has been 
rejected 

Tran_spread_attached - this stores an indication as to whether or not 
details of a spread are attached 



20 



Since the trannumber field is linked to all the other "tran" fields, by selecting 
a particular unique transaction number from the TRAN table 37, for example by 
25 double clicking on it, access can be gained to all the associated data on that 
transaction. 
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Additionally provided is another dynamic table, SPREAD, which contains 
extended information for spreads. This table is linked to the TRAN table 37 
the field that contains the indication as to whether or not details of a spread 
attached. Each new spread is allocated a spread number as well as a transaction 
number, these numbers being identical. This allows the two tables to be tied 
together. The spread number is stored in a s P read_number field in the SPREAD 
table 38, as shown in Figure 3. Linked to the spread_number field are 
"spread." fields that contain details of the products that are being traded, the 
volume of the products, the start and end dates of the spread, the date the spread 
is agreed and the price of the trade. 

Other dynamic tables may be provided as required to cover other trading 
strategies. 

Once registered in the MEMBER table 3 1 and provided with an ID number, a 
trader can log onto the system and so has access to the functionality of the ' 
operating system via a menu table. Control of the facilities that an individual 
user has available to him/her is dictated by the settings in the menu table. Each 
user can act either as a buyer or as a seller. 

In order to gain access to the market operating system, the user must log on by 
entering his unique member number, unique user ID number where appropriate 
and password. This causes the selection, using standard query language, from 
the above-mentioned static and dynamic tables of all entries that include 
reference to the entered unique member number and. where appropriate, the 
unique user ID number. The selected entries from the static tables are listed in 
various customised menus that are subsequently presented to the user in a 
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template of an agreement that is to be completed to represent the deal that was 
previously transacted by telephone. The selected entries from the main 
dynamic table, i.e. the TRAN table 37, are included in a two customised lists. 
The first list provides the user with a summary of the number of trades to which 
he is a party as a seller. The second list provides the user with a summary of the 
number of trades to which he is a party as a buyer. Trades in which the user is 
identified as a buyer are found by matching the login member ID to the counter 
party code in the CPART table and by matching the cpart nmem field in all of 
the records in the TRAN table against the nmem entry in the C PARTY table. A 
hotlink to the TRAN table 37 is provided so that by selecting a transaction from 
the customised list of transactions, for example by double clicking on the 
transaction number, the user can view in tabular form the details of the 
agreement. 

As mentioned previously, in order to confirm a trade it is necessary for the 
seller to specify the terms of the agreed sale. As will be appreciated, in most 
relationships between a buyer and a seller in a particular market there are two 
contractual areas, one that is standardised and another that is variable. The 
standardised business relationships cover areas such as regulatory issues (eg 
"know your customer"), credit terms, insolvency or failure by one of the parties 
to perform under the contracts traded. In the system in which the invention is 
embodied the standardised terms are set out in the User Agreement, to which 
the user must be party in order to register as a member of the market. The 
variable terms relate to the specific contracts into which the parties enter. 

On most bilateral markets and particularly the commodity markets, it is the 
Seller's terms of business which apply and the process may be described as 
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"Seller driven". Following conclusion of a contract, therefore, it is the Seller 
who inputs the trade details and transmits them to the Buyer. The Buyer can 
either accept or reject the trade. Prior to acceptance, the Seller may amend the 
details as he sees fit or may delete the trade altogether. 

In order to confirm a trade a user logs on to the system by entering his unique 
member number and where appropriate unique user ID and password. He then 
selects which of the clearing sites he wishes to use. Alternatively, the default in 
the member table 31 may be set so that the user is automatically presented with 
a pre-determined site. Once this is done, the trader is presented with a list of 
trade options that are selectable in order to construct the agreed sale. For 
example, were the user to enter the "Oilclear" site, the trade options presented 
in the menu could be "crude" or "product". Also included could be spread 
options such as "crude-product" or "crude-crude" or "product-product". If the 
user wishes to confirm a trade one of the trade options would be selected. For 
example if a trader has agreed to sell 15000 barrels of crude oil to counter party 
A, then in order to confirm the deal the user would access the "Oilclear" site 
and select the "crude" option. 

After the trade option is selected the user is presented with a template of an 
offer, as shown in Figure 4, into which information defining the trade must be 
entered in order to confirm the agreement previously made between the traders. 
The trade template includes fields for selecting and/or entering the variable 
terms. When the template is presented to the trader, the user and member fields 
40 and 41 respectively include the name of the member and where appropriate 
the user name. This information is derived from the MEMBER and USERID 
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tables 3 1 and 32 respectively when the trader enters his member and user ID 
numbers and is automatically inserted into the template. 

The template provides a plurality of fields for entering details of the trade for 
example a price field 42 for entering the price of the trade. Menus that allow 
the selection of particular features from the various static tables previously 
described are provided for entry of data into some of the fields. The menus are 
each listed by clicking on the arrows 43 shown in Figure 4. In this way, a 
product can, for example, be entered into the product field 44 by selecting the 
relevant product from a menu listing of products in the PROD table. Likewise 
contract terms can be entered into the terms field 45 by selecting the relevant 
terms from a menu listing of terms in the TERMS table. For example, the 
trader could select the London Metal Exchange terms for metal contracts or 
Shell UK Terms for the so-called " 1 5 Day Brent" contracts. 



Some of the menus list options that are specifically customised for that 
particular user. For example, one such menu lists the counter-parties in the 
CPARTY table that user can use. This menu is compiled by searching the 
CPARTY table for all counter parties that are listed with the user's member 
number and then selecting those counter parties found. Using the counter party 
menu in the template, the user can select the counter party or buyer with whom 
he has made the deal. Once this is selected it is entered into the counter party 
field 46. Likewise a broker can be selected from a menu listing of brokers, 
which is compiled by searching the BROKER table and selecting the brokers 
25 that are listed in the BROKER table that are associated with the member 

number that was entered at log in. Again, once this is selected it is entered into 
the broker field 47. 
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Using oil as an example the trader enters into the template the contract price, eg 
X dollars per barrel, contract quantity, eg X thousand barrels, contract period eg 
"spot" deals for immediate delivery, or a forward date or dates. Contract 
specification can also be defined, within which there may well be further 
variables such as quality (eg Brent Crude Oil, DIN specification Heating Oil), 
delivery location (eg North West Europe, the Gulf, the USA) and delivery terms 
for example on a free on board barge or a cost insurance and freight ocean- 
going vessel. In the case of options or swaps and more complex derivatives, 
further clauses such as the strike price or prices can be included. The 
agreement of these variable terms is in the province of the trader. 



In order to re-construct the agreed trade, the user enters the variable terms, such 
as specific contract terms, the product that is to be traded, for example Brent 
15 Crude Oil, the volume for sale, the duration of the period for which the offer 
will stand, the date of the trade and the price. In addition, the seller must select 
from the customised menu listing that is selected from the CPARTY table, the 
counter party with whom agreement has been reached. The seller may, if 
desired, enter comments on the trade for the buyer to read. 



Each of the terms selected by a seller is included in an appendix to the User 
Agreement. In this way, the overall agreement between the parties to the trade 
is defined. 



Once the user has selected the relevant terms, a message is sent to the buyer 
order to confirm that the terms reflect the agreed trade. This message is sent 
the system server. When the message is received at the server, a unique 



in 
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identification or transaction number is obtained from the TRAN table 37 for 
that trade and the transaction number is entered in the TRAN table 37. The 
transaction number is used for indexing and referencing the trade and the entry 
of a new transaction number indicates that a new transaction has been sent for 
confirmation. The message itself is stamped with the date and the time and an 
audit log is created indicating that an entry has been added to the TRAN table 



37. 



user 



At this stage, stored in the TRAN table 37 are the member number of the 
forwarding the message, which is stored as an index into the MEMBER table 3 1 
and the user ID, which is stored as an index into the USERID table 32. 
Additionally stored is the counter party code, the broker code, if appropriate, 
and the terms code that indicates the terms selected by the user, each of which is 
stored as an index into the corresponding table. Also, the date and time at 
which the agreement was completed are automatically entered into the TRAN 
table 37 date and time fields. Comments entered by the seller for the buyer to 
read are stored in the tran addendum field. 



If the buyer specified in the trade has the CPARTY e-mail initial property set in 
20 their record in the market CPARTY table 35 then the server is invoked to send 
an e-mail to the counter party's e-mail address as entered in the cpart e-mail 
field of the same record. 



When a new trade is received, this is added to the counter-parties' list of 
transactions. The initial alleged sale is of course not a completed transaction 
and so is highlighted accordingly. When the counter-party selects the trade for 
review, details of it are displayed in a tabular format that includes both "accept 
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trade", "reject trade" and "defer" options. The buyer is, however, not able to 
write into or alter any of the terms of the trade that were entered by the seller. 
If the buyer wishes to reject the trade, he selects the "reject trade" option and a 
prompt is generated requesting reasons for the rejection. Once a reason has 
5 been provided, the transaction rejection flag of the transaction record in the 
TRAN table 37 is filled out with the reason and consequently the trade status is 
marked as rejected. The status of the transaction in the seller customised list of 
transactions is then altered to rejected, thereby notifying the seller of the 
rejection. Additionally, the seller may be notified by e-mail. Nothing further 
can be done with a rejected trade until the original seller modifies some aspect 
of the trade information, in which case the status is re-set to that of a normal, 
non-accepted trade by blanking the rejection mark. 

When the seller is notified that a transaction is rejected, he can access the trade 
via his customised list of "seller" transactions and alter any offending terms. 
The transaction is then re-entered into the system and the buyer is again notified 
of its presence. This process continues until the terms are accepted by the 
buyer. 

If a trade is accepted this causes the current date and time to be entered into the 
date and time fields respectively in the transaction record stored in the TRAN 
table 37. This flags that the trade is confirmed for the purpose of future 
enquiries. The status of the trade will be notified to the user via the customised 
list of transactions that is available when the seller is logged onto the system. 
The member number of the trade is also looked up in the member number of the 
CP ART table 35 to determine if the CPART e-mail confirm flag is set. If it is, 
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then an e-mail is sent to the address specified in the CPART e-mail field of the 
counter party's record. 

Once the trade has been accepted and recorded in the TRAN table 37 as such, 
the parties are bound by the terms of the User Agreement and those variable 
terms specified by the seller. 



is 



An advantage of the invention is that central registration of the deal 
conclusive evidence of its existence and there is no need for further telexes, 
faxes or other trade confirmations. In addition the requirement for manual trade 
entry in accounting systems can be removed and trade re-conciliations with 
counter parties are facilitated. 

A physical or offexchange derivative contract can therefore be confirmed and 
given legal status within a straight through process without the need for re- 
entry. It will therefore reside on the user accounting system until it is settled 
either being offset by another position with the same counter party or by 
delivery of the relevant product or cash sum. 

In rejecting a trade, the Buyer may give his reasons in an accompanying text 
message, and it is then possible for the Seller to enter amendments if he agrees 
with the Buyer. 

Where there is a trading dispute in relation to one of the variables of the trade 
such as price or date, then pursuant to the User Agreement, a Referee is 
appointed to set a price at which the trade will be input and registered. This in 
effect crystallises the position between the parties. If there remains a dispute as 
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to any loss resulting then it would be possible for the parties to go to the second 
stage, which is arbitration under the User Agreement. Arbitration is also 
available in relation to disputes over the performance of the contract although 
the parties may prefer to invoke arbitration clauses (eg the London Metal 
Exchange or International Petroleum Exchange clauses) 

The screen that the trader sees is configured to allow him to easily and 
intuitively input the other relevant variable contract terms set out above, which 
he is authorised to agree. This removes the need for certain clerical trader 
support functions. Finally, where a broker arranges a deal but does not act as a 
principal, this fact may be recognised as a further variable term and it will be 
possible to allow brokers to be given "read-only" access to deals in which they 
have been involved. This is a useful administrative tool. 

A skilled person will appreciate mat variations of the disclosed arrangements 
are possible without departing from the invention. Accordingly, the above 
description of a specific embodiment is made by way of example and not for the 
purposes of limitation. It will be clear to the skilled person that minor 
modifications can be made without significant changes to the operation 
described above. 
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Claims 



1. A market operating system for confirming the details of trades already 
agreed between a buyer and a seller, the system comprising an electronic 
controller adapted to communicate via a communication network with a 
seller terminal and a buyer terminal, the electronic controller comprising 
means adapted for registering market members, a memory that includes a 
plurality of contract terms, the contract terms being selectively retrievable 
by a market member from the seller terminal, means for importing a selected 
term into an agreement that is to represent the agreed trade, means for 
storing the agreement completed by the seller, means for sending a signal to 
the buyer terminal to notify the buyer of the presence of the agreement, 
means for allowing the buyer to view the agreement entered by the seller 
and means for receiving a response from the buyer terminal to indicate 
whether of not the agreement is accepted or rejected.. 



2. 



A system as claimed in claim 1 wherein the controller is adapted to provide 
a prompt requesting the buyer to indicate either acceptance or rejection of 
20 the agreement. 



A system as claimed in claim 1 or claim 2, wherein details of the agreement 
are automatically stored in a central database and an indication is provided 
in the database as to whether or not the agreement is accepted or rejected. 



4. A system as claimed in any one of the preceding claims further comprising 
means for selecting a customised list of the contract terms for presentation to 
a particular market member at the seller terminal, the contract terms in the 
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customised list being each selectively retrievable by the particular market 
member from the seller terminal. 

5. A system as claimed in claim 4, wherein a plurality of customised lists is 
5 provided. 

6. A system as claimed in claim 4 or claim 5, wherein the customised list 
includes details of counter parties with whom the market member is 
authorised to trade. 



10 



7. A system as claimed in claim 4 or claim 5 or claim 6, wherein the 
customised list includes details of brokers with whom the market member is 
allowed to trade. 

8. A system as claimed in any one of the preceding claims, wherein each 
member is allocated a member number. 

9. A system as claimed in claim 8, wherein the contract terms that are usable 
by a particular member are stored together with the member number. 

10. A system as claimed in claim 9, wherein the controller is adapted to search 
the stored contract terms to select those terms that are stored together with 
particular member number and use the results of the search to compil 
customised list of contract terms. 



a 
ea 



1 1. A system as claimed in any one of claims 8 to 10, wherein agreements 
entered by the seller are preferably stored together with the member number. 
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12. A system as claimed in any one of the preceding claims, wherein a market 
member designates a user to operate on its behalf in the market operating 
system. 

5 

13. A system as claimed in claim 12, wherein the designated user is an 
authorised employee of the market member. 

14. A system as claimed in claim 12 or claim 13, wherein each user is allocated 
10 a user identification (ID) number and/or a password. 

15. A system as claimed in any one of claims 12 to 14, wherein the controller is 
adapted to store agreements entered by the seller, together with the member 
number and the user ID. 

15 

16. A system as claimed in any one of claims 8 to 15, wherein the controller is 
adapted to allow user access to the system only on receipt of the user 
number member number. 

>o 1 7. A system as claimed in claim 1 6 when dependent on claim 1 4 or 1 5, 

wherein the controller is adapted to allow user access to the system on entry 
of the user ID. 

18. A system as claimed in any one of claims 8 to 17, wherein the controller is 
5 adapted to search the database of agreements on entry of the member 

number, select all those that include reference to the member number 
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entered by the user and present to the user a customised listing of all the 
agreements found. 

19. A system as claimed in claim 18, wherein the customised listing of all the 
5 agreements includes an indication as to whether the agreement has been 

accepted or rejected. 

20. A system as claimed in any of the preceding claims, wherein the controller 
is adapted to receive information from the seller terminal relating to the 

io nature and price of the goods for sale in the market, which information is 

imported into the agreement. 

2 1. A system as claimed in any one of the preceding claims, wherein the 
controller is adapted to receive a signal from the buyer terminal indicative of 

15 whether or not the agreement is accepted or rejected as representing the 

trade previously agreed. 

22. A system as claimed in any one of the preceding claims, wherein an encoder 
is provided for encrypting the details of the agreement so that the offer is 

20 readable only by the selected buyer. 

23. A system as claimed in any one of the preceding claims, wherein the 
controller is adapted to present at the seller terminal a template of the trade 
agreed between the seller and buyer, the details of which are to be 

25 completed by the seller. 
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24. A system as claimed in claim 23, wherein the template includes a menu that 
can be opened, thereby to allow the seller to select contract terms for 
incorporation into the agreement. 

25. A system as claimed in claim 24 when dependent on claim 4 or any claim 
dependent on claim 4, wherein the menu is a listing of the customised list. 

26. A method for confirming the details of trades already agreed between a 
buyer and a seller, the method comprising: 

registering market members; 

storing a plurality of contract terms, the contract terms being selectively 
retrievable by a market member from the seller terminal; 

importing a selected contract term into an agreement that is to represent 
the agreed trade; 

storing the agreement completed by the seller; 

sending a signal to the buyer terminal to notify the buyer of the presence 
of the agreement, 

allowing the buyer to view the agreement entered by the seller, and 
receiving a response from the buyer terminal to indicate whether or not 
the agreement is accepted or rejected. 

27. A computer program for controlling communication between a seller 
terminal and a buyer terminal, the computer program comprising means for 
registering market members, means for presenting to a market member at 
the seller terminal a plurality of contract terms that is stored in memory, 
means adapted to enable selection of a desired contract term from the list 
using the seller terminal, means for including the selected term in an 
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agreement, means for storing the agreement completed by the seller, means 
for sending a signal to the buyer terminal to notify the buyer of the presence 
of the agreement and means for receiving a response from the buyer 
terminal to indicate whether or not the agreement is accepted or rejected.. 

28. A computer program as claimed in claim 27 further comprising means for 
selecting a customised list of the contract terms for presentation to a 
particular market member at the seller terminal, the contract terms in the 
customised list being each selectively retrievable from the customised list by 
the particular market member from the seller terminal. 

29. A computer program as claimed in claim 28 adapted to provide a plurality of 
customised lists. 

30. A computer program as claimed in claim 28 or 29, wherein the customised 
list includes details of counter parties with whom the market member is 
authorised to trade. 

3 1 . A computer program as claimed in claim 28 or 29 or 30, wherein the 
customised list includes details of brokers with whom the market member is 
allowed to associate. 

32. A computer program as claimed in claim 3 1 , wherein means are provided 
for allocating to each member a member number. 



V 
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33. A computer program as claimed in claim 32 wherein the contract terms that 
are usable by a particular member are stored together with the member 
number. 

5 34. A computer program as claimed in claim 33 when dependent on claim 28 or 
ant one of the claims dependent on claim 28, comprising means adapted to 
search the stored contract terms to select those terms that are stored together 
with a particular member number and use the results of the search to 
compile the customised list of contract terms. 

10 

35. A computer program as claimed in any one of claims 27 to 34, comprising 
means adapted to present to a seller a template of an agreement into which 
the seller enters details of the trade that is to be confirmed. 

15 36. A computer program as claimed in claim 35, wherein the template has a 
plurality of data entry fields. 

37. A computer program as claimed in claim 36, wherein data can be entered 
into at least one of the data entry fields by selection from that list. 

20 

38. A data storage means containing a computer program for controlling 
communication between a seller terminal and a buyer terminal, the program 
comprising means for registering market members, means for presenting to 
market members at the seller terminal a list of contract terms that is stored in 

25 memory, means adapted to enable selection of a desired contract term from 

the list using the seller terminal, means for including the selected term in an 
agreement, means for storing the agreement completed by the seller, means 
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for sending a signal to the buyer terminal to notify the buyer of the presence 
of the agreement and means for receiving a response from the buyer 
terminal to indicate whether or not the agreement is accepted or rejected. 

39. A method of establishing an electronic market operating system, the method 
comprising 

registering a plurality of market members; 

providing lists of available products that are selectable by market users; 
providing a plurality of contract terms, and 

marking the contract terms so that they are selectable for incorporation 
into a customised list of contract terms for presentation to a particular market 
member. 



40. A method as claimed in claim 39, further comprising the step of presenting 
the contract terms in the customised list to the particular market member at the 
seller terminal, providing means to allow selection by the particular market 
member of contract terms from the customised list and electronically importing 
the selected terms into a pre-determined user agreement. 

41. A method of gathering market information comprising 

establishing an electronic market operating system for confirming details 
of pre-agreed trades as denned in any one of claims 1 to 27, and 

storing anonymously pricing details of all trades confirmed using the 
market operating system. 



:. A market operating system substantially as described hereinbefore with 
reference to the accompanying drawings. 



WO 00/70484 



PCT/GB00/01879 



34 



43. A computer progarm substantially as described hereinbefore with reference 
to the accompanying drawings. 

5 

44. A computer program substantially as described hereinbefore with reference 
to the accompanying drawings. 

45. A method for confirming the details of trades already agreed between a 
buyer and a seller substantially as described hereinbefore with reference to 
the accompanying drawings. 

46. A method of establishing an electronic market operating system 
substantially as described hereinbefore with reference to the accompanying 
drawings. 



. A method of gathering market information substantially as described 
hereinbefore with reference to the accompanying drawings. 
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